其實筆者在開始開發 Mongory 的時候，大約是 2025 年四月。
那時 AI 已有，但還沒火紅。直到 Threads 上開始流行「宮崎駿風格」的 AI 生圖，大眾的視野才真正被吸引到生成式 AI
從此之後，AI 幾乎成了所有人討論的焦點
當大家在用 AI 生成各種服務各種 APP 開始賺錢，筆者還在埋頭刻著 Mongory
像這種時候，筆者心裡其實也曾經浮現一個疑問：
「既然 AI 什麼都能做，還需要 Mongory 這樣的查詢引擎嗎？」

AI 的力量與侷限

AI 確實強大，它能在短時間內生成文章、程式碼、圖片，甚至能幫助我們思考架構與邏輯。
但它的本質是機率性模型，給出的答案大多是「大致正確」，卻未必能保證完全正確。

而在程式系統中，許多地方是 不能容忍誤差 的：

• 資料查詢必須精確，不能「差不多」就好。
• 使用者篩選條件必須透明且可追蹤，不能只有黑箱結果。
• 執行效能必須穩定，不能因為外部 API 狀態而波動。

AI 提供了創造力與靈活性，但它沒辦法取代這些基礎工程的確定性。

消費 abstraction vs. 創造 abstraction

AI 的角色，本質上是 消費 abstraction：
它利用既有的程式庫、演算法、知識體系，把這些抽象層「吃下去」，再轉換成看似自然的輸出。

但 Mongory 的角色，是 創造 abstraction：
它嘗試在查詢與資料之間，建立一個更輕量、跨語言、可嵌入的中介層。這是一個新的抽象層，能讓開發者在不同語言、不同場景下共享同樣的語法與邏輯。

這種「創造 abstraction」的工作，雖然不像 AI 那麼耀眼，卻是整個軟體基建能否長期運作的關鍵。

Mongory 的位置

Mongory 的目標不是和 AI 競爭，而是補上 AI 無法提供的那一塊。

• 確定性：Mongory 的 matcher tree 是完全可解釋的，結果可重現，不會因為「隨機性」而不同。
• 效能與成本：Mongory 在記憶體內執行，不需要呼叫昂貴的雲端 API，也不會有延遲。
• 嵌入性：Mongory 能嵌入任何語言與服務，無論在網路環境或封閉環境，都能直接運行。

換句話說，當 AI 幫你生成了大量資料，你仍然需要一個可靠的引擎去篩選、整理、驗證。這就是 Mongory 想扮演的角色。

要達成期望的 Roadmap

要讓 Mongory 真正站穩「基礎設施」的位置，筆者心裡清楚，這不是靠一時熱情就能做到的。它需要一條明確的 roadmap：

1. 核心穩定：完成 C-core 的 matcher、記憶體池、基礎 API，確保核心運算具備可重現性與穩定性。
2. 多語言橋接：提供 Ruby、Go、JavaScript、Python 等橋接層，降低使用者進入門檻。
3. 效能驗證：透過 micro-benchmark 與實際應用場景測試，證明 Mongory 的效能優勢。
4. 生態整合：打造與 ORM、API Gateway、資料同步器的整合範例，讓開發者看到即時價值。
5. 教育與社群：透過技術文章、Ironman 系列、playground 展示，讓更多人理解 Mongory 的抽象層價值。

這些都是硬功夫，也需要時間，但唯有一步步走完，Mongory 才能不只是「一個小工具」，而是 一個基建等級的 abstraction。

結語

所以與其問「AI 盛行了，Mongory 有何用？」
不如反過來說：正因為 AI 盛行了，我們更需要 Mongory。

AI 讓我們看見無限可能，但系統的骨幹仍然需要可控、可重現的工具。
Mongory 不追求成為舞台上的主角，而是希望成為那些系統背後穩定跳動的心臟。

這或許不是最吸睛的位置，卻是筆者相信能長久存在的位置。